Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename API group "networking" to "controlplane" #1147

Merged
merged 2 commits into from
Aug 28, 2020

Conversation

jianjuns
Copy link
Contributor

Closes #1122

@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e, conformance and network policy tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests.
  • /skip-e2e: to skip e2e tests.
  • /test-conformance: to trigger conformance tests.
  • /skip-conformance: to skip conformance tests.
  • /test-whole-conformance: to trigger all conformance tests on linux.
  • /skip-whole-conformance: to skip all conformance tests on linux.
  • /test-networkpolicy: to trigger networkpolicy tests.
  • /skip-networkpolicy: to skip networkpolicy tests.
  • /test-windows-conformance: to trigger windows conformance tests.
  • /skip-windows-conformance: to skip windows conformance tests.
  • /test-windows-networkpolicy: to trigger windows networkpolicy tests.
  • /skip-windows-networkpolicy: to skip windows networkpolicy tests.
  • /test-hw-offload: to trigger ovs hardware offload test.
  • /skip-hw-offload: to skip ovs hardware offload test.
  • /test-all: to trigger all tests (except whole conformance).
  • /skip-all: to skip all tests (except whole conformance).

@jianjuns
Copy link
Contributor Author

/test-all

@jianjuns jianjuns changed the title WIP: Rename API group "networking" to "controlplane" Rename API group "networking" to "controlplane" Aug 26, 2020
Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this close #1122? The issue was about revisiting all API groups, not just networking?

Do you know if this affects upgrade? IIRC, renaming the API group used in an APIService may create issues, if we stop serving the original API in the Antrea Controller apiserver. As much as possible we should try to concentrate API changes that may affect upgrade within the same release.

@antoninbas antoninbas added api-review Categorizes an issue or PR as actively needing an API review. area/api Issues or PRs related to an API. labels Aug 26, 2020
@jianjuns
Copy link
Contributor Author

Should this close #1122? The issue was about revisiting all API groups, not just networking?

So far we just concluded on this change only. But if you like to keep the issue open, I am fine too.

Do you know if this affects upgrade? IIRC, renaming the API group used in an APIService may create issues, if we stop serving the original API in the Antrea Controller apiserver. As much as possible we should try to concentrate API changes that may affect upgrade within the same release.

There can be period that controller and agent are not at the same version, and then agent cannot watch the computed networkpolicy objects from controller (so networkpolicy changes will not take effect). I feel this is acceptable, but like to hear your thoughts and suggestions.
@tnqn : any thoughts?

@antoninbas
Copy link
Contributor

@jianjuns that's true, but I consider this acceptable given that we haven't released Antrea v1.0 yet. In this case I was more referring to an issue like this one: #494

@jianjuns
Copy link
Contributor Author

Yes I forgot this one! Does it require API group versions not changed too? If not we can keep an empty networking group. But I guess version must be the same too.

Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found some unexpected changes, guess the PR is not done yet.

build/yamls/base/agent.yml Outdated Show resolved Hide resolved
docs/ovs-pipeline.md Outdated Show resolved Hide resolved
docs/prometheus-integration.md Outdated Show resolved Hide resolved
@tnqn
Copy link
Member

tnqn commented Aug 26, 2020

The problem is applying the new yaml won't delete the stale "v1beta1.networking.antrea.tanzu.vmware.com" APIService, but antrea-controller is no longer serving it so we would meet the same issue as #494 as the upgrade test failure shows:

##[error]    upgrade_test.go:96: Deleting namespace 'test-namespace-cyw88041'
##[error]    upgrade_test.go:98: Namespace deletion failed: timed out waiting for the condition
##[error]    basic_test.go:83: The Antrea Pod for Node 'kind-control-plane' is 'antrea-agent-z9rx7'

@antoninbas and I discussed how to deal with it before, we got two options:

  1. Grant antrea-controller serviceaccount the permission of deleting specific APIServices and do it in antrea-controller.
  2. Ask users to use kubectl apply --prune --prune-whitelist=apiregistration.k8s.io/v1/APIService when applying new yaml.

Along with the evolution of APIs, like v1alpha1 -> v1beta1 -> v1, we may need to handle this case anyway.

@jianjuns
Copy link
Contributor Author

jianjuns commented Aug 26, 2020

  1. Grant antrea-controller serviceaccount the permission of deleting specific APIServices and do it in antrea-controller.

I guess let us go this approach. What you think a separate initContainer which can be activated when we need to handle API service in upgrade, and can be removed when not needed? For example, we execute an antctl command or run controller in special mode to do the cleanup.

@antoninbas
Copy link
Contributor

I like the idea of doing it in the Antrea Controller even if it does require additional permissions.
I see that the Controller already has the following permissions:

- apiGroups:
  - apiregistration.k8s.io
  resourceNames:
  - v1beta1.system.antrea.tanzu.vmware.com
  - v1beta1.networking.antrea.tanzu.vmware.com
  resources:
  - apiservices
  verbs:
  - get
  - update

It seems that wildcards are not supported in resourceNames, so we would need to either give the Controller "delete" access to all APIServices, or make sure that we always include all deprecated APIs in resourceNames.

Copy link
Contributor

@abhiraut abhiraut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mid way i saw you plan to address goland mistakes..

build/yamls/base/agent.yml Outdated Show resolved Hide resolved
docs/ovs-pipeline.md Outdated Show resolved Hide resolved
pkg/agent/agent.go Outdated Show resolved Hide resolved
pkg/agent/agent_windows.go Outdated Show resolved Hide resolved
pkg/agent/agent_windows.go Outdated Show resolved Hide resolved
pkg/agent/config/node_config.go Outdated Show resolved Hide resolved
pkg/agent/doc.go Outdated Show resolved Hide resolved
pkg/agent/openflow/client.go Outdated Show resolved Hide resolved
pkg/agent/route/route_windows.go Outdated Show resolved Hide resolved
pkg/agent/route/route_windows.go Outdated Show resolved Hide resolved
@abhiraut
Copy link
Contributor

I like the idea of doing it in the Antrea Controller even if it does require additional permissions.
I see that the Controller already has the following permissions:

- apiGroups:
  - apiregistration.k8s.io
  resourceNames:
  - v1beta1.system.antrea.tanzu.vmware.com
  - v1beta1.networking.antrea.tanzu.vmware.com
  resources:
  - apiservices
  verbs:
  - get
  - update

It seems that wildcards are not supported in resourceNames, so we would need to either give the Controller "delete" access to all APIServices, or make sure that we always include all deprecated APIs in resourceNames.

+1 seems okay to grant this to Antrea controller with specific resource names

@jianjuns jianjuns changed the title Rename API group "networking" to "controlplane" WIP: Rename API group "networking" to "controlplane" Aug 26, 2020
@jianjuns
Copy link
Contributor Author

Thanks @abhiraut for the review. Let me do a thorough check of all changes.
For APIService cleanup, I am still thinking about an initContainer. Will do some tests first.

@jianjuns jianjuns force-pushed the apigroup branch 2 times, most recently from 732e426 to 81c4e8c Compare August 27, 2020 00:28
@jianjuns jianjuns changed the title WIP: Rename API group "networking" to "controlplane" Rename API group "networking" to "controlplane" Aug 27, 2020
@jianjuns
Copy link
Contributor Author

After looking at the code, I also agree let controller delete the APIService is much simpler, as controller now already updates APIServices. Made the change. Please check. @antoninbas @abhiraut @tnqn

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deletion logic LGTM, a few comments

Comment on lines 179 to 180
// otherwise K8s will reject to delete an existing Namespace created
// before the upgrade. Also check the information at:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: s/will reject to delete/will fail to delete

also question: is it just for Namespaces that existed before the upgrade? I thought that was for all Namespaces (because every time a Namespace is deleted, K8s reaches out to all APIServices to see if they have any object that needs to be deleted). See kubernetes/kubernetes#60807 (comment). I may be wrong though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to "will fail to delete".

You are right. It should be all Namespaces before the APIService is deleted. Updated the comments.

pkg/apiserver/apiserver.go Outdated Show resolved Hide resolved
pkg/apiserver/apiserver.go Outdated Show resolved Hide resolved
@@ -130,6 +130,12 @@ func run(o *Options) error {
if err != nil {
return fmt.Errorf("error creating API server: %v", err)
}

err = apiserver.CleanupDeprecatedAPIServices(aggregatorClient)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think of it too much but does the order matter here? should we remove deprecated APIServices before installing the new ones?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Installation happens locally on controller, and new APIServices are already registered when applying the YAML. Before apiserver starts, K8s knows nothing about the new API groups. So, I think it does not matter.

resources:
- apiservices
resourceNames:
# Add the APIServices for the deprecated APIGroups here. antrea-controller
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the comment!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have a timeline in terms of releases for how long we plan to attempt deleting old apiservices? ie after X releases we will no longer clean up..

@jianjuns jianjuns force-pushed the apigroup branch 2 times, most recently from 91c35fc to 4a819c0 Compare August 27, 2020 05:44
@jianjuns
Copy link
Contributor Author

/test-all

pkg/apiserver/apiserver.go Outdated Show resolved Hide resolved
tnqn
tnqn previously approved these changes Aug 28, 2020
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jianjuns
Copy link
Contributor Author

/test-all

tnqn
tnqn previously approved these changes Aug 28, 2020
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

antoninbas
antoninbas previously approved these changes Aug 28, 2020
Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

abhiraut
abhiraut previously approved these changes Aug 28, 2020
Copy link
Contributor

@abhiraut abhiraut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.. one minor nit.. but lets merge so we can resolve conflicts on other PRs

resources:
- apiservices
resourceNames:
# Add the APIServices for the deprecated APIGroups here. antrea-controller
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have a timeline in terms of releases for how long we plan to attempt deleting old apiservices? ie after X releases we will no longer clean up..

pkg/apiserver/apiserver.go Outdated Show resolved Hide resolved
@antoninbas
Copy link
Contributor

@abhiraut I think we should keep including all deprecated APIServices until we make a v1.0 release

@abhiraut
Copy link
Contributor

@abhiraut I think we should keep including all deprecated APIServices until we make a v1.0 release

thanks for the answer!

@codecov-commenter
Copy link

codecov-commenter commented Aug 28, 2020

Codecov Report

Merging #1147 into master will decrease coverage by 0.30%.
The diff coverage is 17.11%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1147      +/-   ##
==========================================
- Coverage   43.79%   43.48%   -0.31%     
==========================================
  Files         140      140              
  Lines       15146    15246     +100     
==========================================
- Hits         6633     6630       -3     
- Misses       7928     8027      +99     
- Partials      585      589       +4     
Flag Coverage Δ
#integration-tests 31.23% <0.55%> (-0.29%) ⬇️
#unit-tests 39.84% <90.24%> (-0.06%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/agent/cniserver/ipam/testing/mock_ipam.go 100.00% <ø> (ø)
pkg/agent/cniserver/server.go 51.69% <ø> (ø)
pkg/agent/controller/networkpolicy/cache.go 79.57% <ø> (ø)
pkg/agent/controller/networkpolicy/reconciler.go 67.92% <ø> (ø)
pkg/agent/openflow/network_policy.go 74.45% <ø> (ø)
pkg/agent/route/testing/mock_route.go 40.74% <ø> (ø)
pkg/agent/types/networkpolicy.go 25.00% <ø> (ø)
pkg/antctl/antctl.go 100.00% <ø> (ø)
pkg/antctl/command_definition.go 45.43% <ø> (ø)
...lusterinformation/v1beta1/zz_generated.deepcopy.go 0.00% <ø> (ø)
... and 35 more

@jianjuns
Copy link
Contributor Author

/test-all

@jianjuns jianjuns merged commit b2af9f4 into antrea-io:master Aug 28, 2020
antoninbas pushed a commit to antoninbas/antrea that referenced this pull request Sep 3, 2020
* Rename API group "networking" to "controlplane"

* Delete the registered APIService for "networking" API group
antoninbas pushed a commit to antoninbas/antrea that referenced this pull request Sep 3, 2020
* Rename API group "networking" to "controlplane"

* Delete the registered APIService for "networking" API group
antoninbas pushed a commit that referenced this pull request Sep 3, 2020
* Rename API group "networking" to "controlplane"

* Delete the registered APIService for "networking" API group
GraysonWu pushed a commit to GraysonWu/antrea that referenced this pull request Sep 22, 2020
* Rename API group "networking" to "controlplane"

* Delete the registered APIService for "networking" API group
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-review Categorizes an issue or PR as actively needing an API review. area/api Issues or PRs related to an API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adjust API groups for Controller API and CRDs
7 participants